**Description**
Switch a couple of unchecked assertions to normal assertions because
they had no safety justification that worked locally. The assertions
weren't currently in danger of causing an issue, but future changes
could have put them in violation without more explicit docs on the
containing function. Better to upgrade to panic for now.

**Testing Done**
Ran fuzzer and existing unit tests.

**Description**
The `InnerNodeSorted::range` function had bugs when translating the
lookup bound and search results into array bounds. Specifically the issue
was in handling `Bound::{Included, Excluded}(WritePoint::Last(_))`, there
was some adjustments needed when using the bound as a start vs end bound.

**Motivation**
These bugs were not exercised in the normal lookup process, only in the
`TreeMap::range` iterator lookup process, which had a bunch of other bugs
unrelated to these.

**Testing Done**
Added some more unit tests, ran through fuzzer.

**Description**
This commit fixes bugs across all conditions of the range iterator
internals. All the bugs were concentrated in the code which finds the
correct start or end leaf node for the iterator when the range search
ends on an internal node. Specifically:
 - For the "missing child" termination reason (which happens when the
   lookup stops because there is no inner node child for the next key
   byte), there was an incorrect early return if the child node lookup
   returned `None`. Instead it should have turned that `None` case into
   a lookup on the minimum subtree child or maximum subtree child
   depending on the case.
 - The "insufficient bytes" and "prefix mismatch" cases were clumped
   together incorrectly. Splitting out "insufficient bytes" case
   simplified its logic. Similarly, clarified the "prefix mismatch" case,
   I think there was also a bug in there with the different cases of
   min/max and next/previous.
 - Switched from using the optimistic/pessimistic lookup optimization to
   just looking up the full prefix of an inner node when needed for
   range search. The optimistic case of the optimization was a problem
   for correctly classifying something as "insufficient bytes" versus
   "prefix mismatch", since implicit bytes make it impossible to tell
   which was the real cause.

I added a bunch of comments around the range leaf node lookup logic, I
hope I got it right this time. Also cleaned up some now dead code.

**Motivation**
When I added the oracle fuzzer for the range iterator in a previous
commit, it kept turning up regressions. I think I went through 3
different cases, rewriting the range lookup code, before I realized I
needed to remove the optimistic/pessimistic optimization from this code
path.

**Testing Done**
Added a bunch of unit tests, all pass. Fuzzer also ran for one hour
without finding any new issues.